The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior aft by inclusion in this section.
Software applications operating in a network environment exchange application messages. An “application message,” or simply “message”, as used herein, refers to a message emitted or consumed by a software element that is logically located at Layer 5 or higher of the OSI reference model. Messages may be contained in more than one data frame, packet or segment. For simplicity, the term “packet” is used to refer to a unit of organization under an internetworking protocol, such as data frame, packet or segment, at Layer 2, 3 or 4 of the OSI reference model.
Application end points such as clients and servers in a distributed system communicate over a network using many different transport layer protocols such as HTTP, JMS, SMTP, FTP, etc. Independent of the transport layer protocols, messages themselves can have their own formats such as XML, TEXT, BINARY, etc. In addition to standard formats, applications sometimes use their own proprietary message formats as well as proprietary transport protocols that are best suited for their requirements.
Additionally, as applications need to interact with other networked applications which use their own proprietary or standard transport protocols and message formats, the messages that travel from one application to another may need different custom processing for both transport level protocols and custom business logic.
Application message formats are not static and may change to support business needs. The business logic code that processes these application messages must change to support the new message formats. On the other hand, the same application message may be transmitted using different protocols to support business needs. Custom protocol handlers may need to handle the processing of these messages over the new transport protocol.
Generally, in past approaches, in order to handle any of these changes, the implementation of the application has to be changed, the application has to be reloaded into the network device, and the network device has to be restarted. This is time-consuming, requires significant resources in programming labor, and is disruptive to network operations. Further, in typical past approaches, the number of servers on which the applications run is much higher than the number of network elements that interconnect them. The custom business logic for handling different message formats and transport protocols must be provisioned and managed on all the servers, which is time-consuming and labor-intensive.